3. Scenario 3: ISV Cloud Service
In this scenario,
an independent software vendor (ISV) named My Energy has an
energy-management cloud service that it offers to multiple utility
companies. The service performs data collection from power meters on
houses and commercial buildings and offers this data to utility
companies for reporting and processing. Currently, the ISV service has
its own identity-management database and for every utility company. Due
to resource constraints, maintaining identities of all the utility
partner companies has turned into an expensive process. Every time an
employee of a utility company quits, My Energy has to remove the employ
from the database. My Energy wants to reduce its identity-management
costs because it's turning out to be a significant portion of the
company's support operating expenses. Assuming that utility companies
have an identity federation infrastructure, I recommend that My Energy
implement a claims-based identity model using ACS as the
claims-transformation engine. My Energy can use ACS to map claims
issued by a utility company's identity federation server (such as ADFS
2.0) to claims required by the My Energy service.
The recommended design is illustrated in Figure 3.
The following steps describe the flow of information for the My Energy web application:
Step 0:
In this step, similar to previous scenarios, the My Energy
administrator establishes trust relationships between My Energy, ACS,
and the identity providers of utility companies. Then, the My Energy
administrator configures ACS by mapping input claims from the identity
providers to output claims specific to the My Energy application.
Step 1:
When a utility company employee wants to sign in to the My Energy
service, the employee authenticates with the utility company's identity
federation server and receives a SAML token.
Step 2:
The SAML token is sent to ACS. Because ACS is configured to trust the
company's identity federation server, ACS can accept input claims from
the issuer. The SAML token consists of input claims to ACS.
Step 3:
ACS maps the input claims from the SAML token to output claims specific
to the My Energy service and packages them into a secondary SWT.
Step 4:
The SWT with output claims is sent to the My Energy service for
processing. The My Energy service processes these claims and determines
the level of access the utility company's employee is entitled to.
Using ACS, the My
Energy service can support multiple utility companies without managing
their identities in its own identity store. The identity costs involved
mainly involve claims mapping and establishing trust between identity
providers and ACS; but these are one-time efforts per utility company.
After trust is established and claims are configured, the claims-based
identity process will work seamlessly for My Energy. The My Energy
service no longer maintains a separate identity-management store,
because users are authenticated against the utility company's identity
store. My Energy is configured only to process output claims coming
from ACS.
The three scenarios discussed identify the following ACS advantages:
ACS federates between wide varieties of identity providers because of its standards-based interface.
ACS abstracts identity management from your application or service.
ACS abstracts out authorization management from your application or service.
ACS can help achieve single sign-on across diverse systems because of its standards-based API.
ACS
works with web browsers and web applications (passive participants) as
well as smart clients and web services (active participants).
ACS
provides an STS for issuing SWT tokens containing output claims. Every
mapping scope can be considered to have its own virtual STS.
4. Retrieving Tokens from ACS
You can retrieve an SWT
token from ACS three ways: using plain text, by sending an SWT, or by
sending a SAML token. ACS supports only SSL transmission of the tokens
over HTTP POST. ACS always issues an SWT output token that consists of
output claims the relying party expects. Figure 4 illustrates these token-retrieving methods.
In the plain text
method, the issuer key is directly sent to ACS. In the SWT method, the
client application creates an SWT token to authenticate with ACS and
sends the token to ACS. In the SAML token method, a client acquires the
SAML token from a SAML token provider like ADFS v2.0 or a custom STS
and sends it to ACS for requesting an output SWT token.
